Rule-based method for designing user interfaces for applications

ABSTRACT

A computer-implemented method for a system having a database and a plurality of application software interfaces, the method including steps of reading a control type from a plurality of control types stored in the database, selecting an application software interface having a pointer based on the control type, defining an identification code for the control type, storing the pointer and the identification code and linking a first node to a second, subsequent node of control types and creating a linked list of the plurality of control types.

BACKGROUND OF THE INVENTION

The present invention generally relates to designing and maintaininguser interfaces, and more specifically to a method for designing graphicuser interfaces (GUI) based on rules.

Description of the Related Art

Current computer languages provide Application Program Interfaces(APIs), to generate "child windows" or sub-windows for controls such asEntry Fields, List Boxes, Radio Buttons and Push Buttons.

For purposes of this application, a "child window" is defined as awindow that is dependent on main or parent windows to receive all mouseand keyboard inputs. Every application creates at least one window. Eachwindow plays some part in displaying outputs and/or receiving inputsfrom the user.

An application window can use several types of subordinate windows likeframe windows, client windows, control windows, dialog windows, messageboxes, menu, etc. This invention involves programming control windowslike entry fields, list boxes, radio buttons and push buttons. Controlwindows can also be referred to as child windows. For purposes of thisapplication a child window or control window is defined as a window thatis dependent on main or parent windows to receive all mouse and keyboardinputs. Selecting a control window will indicate if a selection is madeor initiate certain action when actuated or clicked on by the user(e.g., clicked on either by mouse or pressing "enter" key on thekeyboard).

Entry fields are defined as a control field into which a user placestext. The limit on the total number of characters in the field can bepreset.

List boxes are defined as a control that contains a list of objects orsettings choices that a user can select. List boxes are windowsdisplaying the choices that users can scroll up or down.

Radio buttons are defined as controls combined to show a user a fixedset of choices from which the user can select one. Radio buttons aredepicted as a circle with text beside it. The circle is partially filledor darkened when chosen or clicked on by a mouse pointer.

Push buttons are controls appearing as a button, filled with text orgraphics that will initiate certain action when the user selects it bypressing the "enter" key on the keyboard, or by single clicking themouse pointer on it.

FIGS. 8A and 8B illustrate common examples of entry fields 81, listboxes 82, radio buttons 83 and push buttons 84.

Designing and programming such user interfaces in a time efficientmanner and at a minimum cost is an important consideration in thepreparation of APIs.

In the conventional systems and methods, the Application Program (AP)code must be modified in order to change window layouts and/orconfigurations of the controls within the application window. Moreover,the coordinates and layouts of the controls are generally "hard coded"within the AP. For purposes of this application, "hard coded" means thata window size and position are explicitly specified in the program code.

Therefore, a problem arises when a change in the window layout isdesired in that the AP must be recompiled, reloaded and run in order todetermine the effects of the changes made to the controls or fields.This is computationally very time-consuming and very inefficient.

Further, in the conventional systems and methods, one AP controls onewindow and its layout at any given time. Such dedicated control occursbecause it is simpler to code and maintain. However, such dedicatedcontrol adds to the development and maintenance costs of the software.

Other problems of the conventional systems and methods include that thelines of code increase as the number of windows increases in a specificapplication. Adding new code to enhance the application is also a majorundertaking in the conventional systems.

SUMMARY OF THE INVENTION

It is, therefore, an object of the present invention to overcome theabove problems of the conventional systems and methods, and morespecifically to provide a method for designing graphic user interfaceswhich are rule-based.

According to the present invention, an innovative universal methodologyis provided which invokes the layouts of the fields, pertinent to anapplication window, to thereby overcome the above problems of theconventional systems and methods.

In a first aspect of the invention, a computer-implemented method for asystem having a database and a plurality of application softwareinterfaces is provided. The method includes steps of reading a controltype from a plurality of control types stored in the database, andselecting an application software (program) interface having a pointerbased on the control type. Thereafter, an identification code is definedfor the control type, and the pointer and the identification code arestored. Finally, a first node is linked to a second, subsequent node ofcontrol types and a linked list of the plurality of control types iscreated.

The methodology employed in the present invention not only maintains thesimplicity and maintainability of the code but also lowers productioncosts. Specifically, the invention makes it easier to build newerapplications as repetitious code is consolidated by the inventivemethod.

With the present invention, an application developer can design a GUI byeliminating the recompilation and reloading time by an order ofmagnitude. The application code to generate child windows can be simplywritten once and can be reused for other application, thus saving ondevelopment and maintenance. The invention allows the predefinedcontrols to be extremely flexible and changeable, without affecting theapplication code.

Thus, with the present invention, the Application Program code need notbe modified in order to change window coordinates and/or configurationsof the controls within the application window. Moreover, the coordinatesand layouts of the controls need not be "hard coded" within the AP.Hence, when a change in the window layout is desired, the AP does nothave to be recompiled, reloaded and run in order to determine theeffects of the changes made to the controls or fields. As a result, aquick computation can be made and the system has increased efficiency.Another advantage is that the structure and method of the invention doesnot require that one Application Program control a respective one windowand its layout at any given time, as in the conventional methods. Thus,development and maintenance costs of the software are reduced, ascompared to the conventional systems and methods.

Other advantages of the present invention include reuse of code forother applications, lowering of maintenance costs and maintaining thesimplicity of code. The present invention can be implemented on anygraphic user interface-based operating system.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and other objects, aspects and advantages will be betterunderstood from the following detailed description of a preferredembodiment of the invention with reference to the drawings, in which:

FIG. 1 is a block diagram showing a hardware configuration on which thesubject invention may be implemented.

FIGS 2A and 2B illustrate tables in which rules for the user interfacesare defined according to a preferred embodiment of the presentinvention.

FIG. 3 is a block diagram illustrating data for a List Box and a RadioButton according to the preferred embodiment of the present invention.

FIGS. 4A and 4B are block diagrams illustrating a flow chart of thepreferred method of the present invention.

FIGS. 5A-5C illustrate various control items within display screensaccording to the present invention.

FIG. 6 is a block diagram which illustrates a Linked List according tothe present invention.

FIG. 7 illustrates a display screen according to the present invention.

FIGS. 8A and 8B Illustrate Entry Fields, List Boxes, Radio Buttons andPush Buttons.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT OF THE INVENTION

Referring now to the drawings, and more particularly to FIG. 1, there isshown for the present invention an exemplary hardware environment whichmay include a personal computer, such as the International BusinessMachines (IBM) Corporation's Personal System/2 (PS/2) family of PersonalComputers.

The hardware includes a central processing unit (CPU) 10, which mayconform to Intel's X86 architecture or may be a reduced instruction setcomputer (RISC) microprocessor such as IBM's PowerPC microprocessor.

The CPU 10 is attached to a system bus 12 to which are attached aread/write or random access memory (RAM) 14, a read-only memory (ROM)16, an input/output (I/O) adapter 18, and a user interface adapter 22.The RAM 14 provides temporary storage for application program code anddata, while ROM 16 typically includes the basic input/output system(BIOS) code.

The I/O adapter 18 is connected to one or more Direct Access StorageDevices (DASDs), such as for example a floppy drive 19, a hard diskdrive 20 and a CD-ROM 21. The hard disk drive 20 typically stores thecomputer's operating system (OS), such as IBM's OS/2 operating system,and various application programs, each of which are selectively loadedinto RAM 14 via the system bus 12. The user interface adapter 22 hasattached to it a keyboard 24, a mouse 26, and/or other user interfacedevices (not illustrated).

The personal computer or workstation also includes a display 38, whichmay be, for example, a cathode ray tube (CRT) display but which also maybe a liquid crystal display (LCD) or other suitable display. The display38 is connected to the system bus 12 via a display adapter 36. Amultimedia adapter 34, such as Intel Corporation's Action Media IIDisplay Adapter, is connected to the bus 12 and to a microphone 32, aspeaker 28 and a video camera 30 for audio/video capture and playback.The multimedia adapter 34 is supported by suitable software, such asIBM's Multimedia Presentation Manager/2. The inventive approach has beenimplemented in Smalltalk/OS2 as part of the Isis Authoring Environment.

As will be understood by those skilled in the art, other hardware andsoftware also may be incorporated into the system depending upon thedesigner's requirements and constraints.

Briefly and as mentioned above, the invention provides a methodology inwhich user interfaces can be suitably altered at any time throughout thelife of the application, without any changes to the application codeactually occurring or being required, thereby reducing compilation timeand reducing the risk of introducing "bugs" (e.g., defects) into theapplication. The same code also may be used to arrange the layout ofcontrols in other parent windows, thereby saving substantially onsoftware development and maintenance costs. Indeed, the application codeto generate "child window" is written only once and can be reused forother applications.

Generally, all user interface applications contain controls such as, forexample, Entry Fields, List Boxes, Check Boxes, Radio Buttons, which aredescribed in detail above. Other controls are also envisioned asrequired by the designer.

The operating system, such as Presentation Manager in OS/2 or the likewhich may be used with the present invention, provides APIs to defineand interact with these controls. An application creates a window byusing any operating system graphics manager provided API (e.g., inPresentation Manager at OS/2 WinCreate Window is the API).

The minimum required information for these APIs is window name, parentwindow, window position relative to the parent window, window width andheight, window style, window identifier and some window specificinformation.

Window name is a text string that identifies the window and its purposefor the user.

Parent window provides the coordinate system used for positioning thewindow and defines the relationship the child window has with othersibling windows. The parent window also alters the appearance andbehavior of child window (e.g., in Presentation Manager on OS/2 if aparent window is hidden, the child window is also hidden).

Regarding window position, every window has a position and size. Theposition is specific to the location of the window on the screen of thewindow's lower left corner. This position is relative to the lower leftcorner of the parent window (in pixels).

Regarding window width & height, a windows size is the width and heightof a window (x axis, y axis in pixels).

Every window can have a style which defines how a window looks orbehaves. Some styles are specific to certain types of windows.

A window identifier uniquely identifies a window with a givenapplication. This identifier will identify a sender of messages.

When a window is created, the API returns a window handle. The handle isa unique value for every window that is created. The handle is used tosend a message to a given window or direct it to execute some action.

The window's size and position are coordinates expressing the boundariesof the drawn window on the screen. The default coordinate systemspecifies that the point (0,0) (X axis, Y axis) is at the window lowerleft corner. Coordinates generally increase upwards and to the right.

These coordinates can be specified when a window is created or can bechanged at any time.

According to the inventive method, for all controls that will appearwithin a parent window, a database containing rules is defined in atabular format, such as the tables illustrated in FIGS. 2A and 2B.

The exemplary tables of FIGS. 2A and 2B illustrate six columns whichrespectively contain the Control Type 21, Coordinates 22, Unique ID 23,Parent 24, Owner 25 and Miscellaneous Information 26. The Table may haveany number of columns depending on the designer's requirements and theTables of FIG. 2A and 2B are merely exemplary.

Specifically, the Control Type column 21 includes information regardingthe type of control to be drawn in the given window on the displayscreen. For example, the control types (e.g., "child windows") mayinclude a Check Box, Push Button, Radio Button, Entry Field or a ListBox, as discussed above. Other types of windows also are possible suchas main windows for an application program, message boxes, staticcontrol that displays text or icon data, check box, three state buttonand others.

The Coordinates column 22 identifies the position on the display screenof the control. For example, the position of the Check Box would be 1,22, 30, 10 according to the Table shown in FIG. 1. This means that theCheck Box will be positioned at the following coordinates x=1 pixel,y=22 pixels and have a length of 30 pixels and a height of 90 pixels.All units are measured in pixels of the display screen. FIG. 5Aillustrates the appearance of Check Box 52 within a parent window 51according to the parameters set forth in the table illustrated in FIG.2A.

Similarly, FIG. 5A illustrates the appearance of the Push Buttonaccording to the parameters set forth in FIG. 2A. FIGS. 5B similarlyillustrates the appearance of Radio Buttons. FIG. 5C illustrates theappearance of an Entry Field and a List Box according to FIG. 2A.

FIG. 2B relates to the push buttons illustrated in FIG. 7. Specifically,the push button with unique ID 560 is push button 71. The push buttonwith unique ID 561 is push button 72. The push button with unique ID 562is push button 73. The entry field with unique ID 563 is test button 74.

Referring to FIG. 5A, the position of the control (a check box 52) isrelative to a lower left corner (0,0) of the parent window 51. The checkbox 52 will be drawn in window 51 after window 51 is displayed. The sizeof the check box 52 is, for example, 30 pixels long by 10 pixels high.If the position and size coordinates are not specified, PresentationManager in OS/2 or other API will assign default values.

The coordinates column 22 also defines the position of the other controltypes, including the position of the Push Button, Radio Button, EntryField and List Box.

The Unique ID column 23 contains an identification code for each of thecontrol types. For example, the identification code of the Check Boxwould be 529 which identifies the window. A window identifier makes eachwindow unique in conjunction with other windows. This identifier letsthe window identify itself when it sends information to the ownerwindow. This identifier is required when defining any new window ordisplay.

The Unique ID column 23 also defines an identification code for each ofthe other control types listed in the Control Type column 21.

The Parent column 24 identifies which window is the parent of a givencontrol type. A window is designated a "parent" of a control type whenthe control window will be drawn within its boundaries/coordinates.Every window created needs a parent window in Presentation Manager underOS/2. Other graphical managers also require identifiers.

For example, referring to FIG. 5A window 51 would be the parent of theCheck Box 52 and the Push Button 53. Referring to FIG. 5B, window 54would be the parent of the Radio Button 55. Referring to FIG. 5B, window56 would be the parent of the Entry Field 58 and the parent of the ListBox 57.

These relationships are designated by the applicationprogrammer/designer in advance. The designer will define theserequirements as rules in the table (FIGS. 2A and 2B). According to thepresent invention, if the programmer/designer wants to change therelationships, only the rules need be changed. The code or program doesnot need to be modified.

Similarly, the Owner column 25 identifies which window is the owner of agiven control type. For example, window 1 would be the owner of theCheck Box and the Push Button, window 2 would be the owner of the RadioButton, window 3 would be the owner of the Entry Field and window 4would be the owner of the List Box.

The significance of a window being the "owner" of a control type is thatan owner window coordinates the activities of a window in reference toother windows that are also displayed. For example, in Program Manager,the window sends messages about its state to its owner window and theowner sends messages about what action to carry out next. An owner issimilar to a parent but does not affect the behavior or appearance ofthe window. The owner field and the parent field must be defined by theprogrammer.

The Miscellaneous Information column 26 contains any type of additionalinformation which is necessary for the effective operation of themethodology. For example, the List Box control type contains a referenceto table 2 shown in FIG. 3, described below. Once the list box controlis defined and drawn in Window 56, then the actual data to be displayedin the list box will be read from FIG. 3 (i.e., data item 1, data item2, data item 3 and data item 4) and displayed in the list box 57 whichhas an identifier of 533.

FIG. 3 illustrates table 2 which contains data for the List Box and theRadio Button. Table 2 within FIG. 3 merely holds data to be displayed inthe respective control. For example, identifier 533 (list box 57) willshow data item 1 through data item 4 from FIG. 3 on the screenillustrated in FIG. 5B. These rows will be read by programmers and codedbased on the control identifier number. For example, identifier 531(radio buttons 55) will show value 1 through value 4 from FIG. 3 aftercontrol identifier 531 or Radio Buttons have been defined in the code.

FIGS. 4A and 4B illustrate a flow chart of steps of each of theexemplary control types of the inventive method for managing, definingand drawing child windows or controls within a parent window.

Specifically, the first step 41 in the flow chart of FIG. 4 is toacquire the window ID and match the same to the parent column 24 inFIGS. 2A and 2B. The next step 42 is to read all the control types fromcolumn 21 in FIGS. 2A and 2B where the parent column 24 is equal to agiven window identification. If the control type is in table 1 (FIGS. 2Aand 2B), then the method proceeds (step 43).

Each control type is then processed according to the following genericsteps. The control type is identified in step 44. Next, in step 45, themethod defines the API for the specific control type by reading the restof the values within the columns 22-26 in Table 1 (FIGS. 2A and 2B) anda handle is retrieved. Finally, the last step 46 stores a unique ID anda pointer or handle to the control type and links the previous node tothe next node to create a Linked List.

Step 45c relating to the List Box includes the extra processing ofreading the miscellaneous information column 26 and referring to table 2(FIG. 3) to obtain the necessary display data

Looking at the inventive methodology in more detail, the first step inthe method is to read in the control types from a given database. Such agiven database would be established by the designer/programmer. Thedatabase is simply a repository of rules of how and where differentcontrols are to be displayed for a given window. This database/storageof rules defines how a window looks and what it contains. The programerwill create APIs based on the given rules. The rules are the sets ofdirections for the application programs.

In the method according to the present invention, for each type ofcontrol (e.g., defined in the database of rules described above and asshown in Table 1 of FIGS. 2A and 2B), a generic case statement isdefined by, for example "create push buttons" (coordinates, unique ID,Parent, Owner and Miscellaneous Information).

An example of a generic case statement is that the total program (realtime) can be one big case statement and, based on the type of controldefined in Table 1 (FIGS. 2A and 2B) which will execute the requiredcode. An example of a case statement is illustrated below entitled"Pseudo Code for Case Statement."

Below is an exemplary Pseudo code for just creating controls in a givenwindow using the IF - - - THEN - - - ELSE statement.

    ______________________________________                                        Psuedo Code                                                                   ______________________________________                                        Read the window ID                                                            Do for all controls in Table 1 for a given parent = window                    If control type = `Push Button`                                               Create Push Button (coordinates, unique ID, parent or                         window ID, owner or window ID, "Title of PB");                                Else if control type = `Check Box`                                            Create check box (coordinates, unique ID, parent or                           window ID, owner or window ID, "Title of CB");                                Else if control type = `Radio Button`                                         Create Radio Button (coordinates, unique ID, parent                           or window ID, owner or window ID);                                            Read in column Misc. Info. for pointer to table that                          stores values                                                                 Do until (no more values);                                                            Read values from table that stores values                                     mapping control ID or unique ID for this RB;                                  create Radio Button (Data);                                           End;                                                                          Else if control type = `Entry Field`                                          Create entry field (coordinates, unique ID, parent,                           owner, "title of EF" from Misc. Info column);                                 Else if control type = `List Box`                                             Create List Box (coordinates, unique ID, parent,                              owner, read pointer to table that stores values in Misc.                      Info column;                                                                  Do until (no more values);                                                            Read data column from given table for given                                   control ID;                                                                   create List Box values (DATA);                                        End;                                                                          ______________________________________                                    

Below is the Pseudo code for creating controls for a given window tostoring these values in a Linked List. This pseudo code uses a casestatement.

    ______________________________________                                        Pseudo code for case statement                                                ______________________________________                                        Read the window ID                                                            Do for all controls in table 1 for the given parent = Window ID               Case (control type)                                                           `Push Button`:                                                                        PB Handle = Create Push Button (coordinates,                                  unique ID, parent ID, owner, "Title of PB");                                  Store unique ID and PB Handle in a Node;                                      Link this Node to existing Linked List of other                               Push Buttons;                                                         `Check Box`:                                                                          CB Handle = Create Check Box (coordinates,                                    unique ID, parent ID, owner, "Title of Check                                  Box);                                                                         Store unique ID and CB Handle in a Node;                                      Link this node to existing Linked List of other                               Check Boxes;                                                          `Radio Button`:                                                                       RB Handle = Create Radio Button                                               (coordinates, unique ID, parent ID, owner,                                    "Title of Radio Button");                                                     Store unique ID & RB Handle in a Node;                                        Link this node to existing Linked List of other                               Radio Buttons;                                                        `Entry Field`:                                                                        EF Handle = Create Entry Field (coordinates,                                  unique ID, parent ID, owner, "Title of Entry                                  Field);                                                                       Store unique ID & EF Handle in a Node;                                        Link this node to existing Linked List of other                               Entry Fields;                                                         `List Box`:                                                                           LB Handle = Create List Box (coordinates,                                     unique ID, parent ID, owner, "Title of List                                   Box);                                                                         Store unique ID & LB Handle in a Node;                                        Link this node to existing Linked List of other                               List Boxes;                                                           End;  * of case statement *!                                                  ______________________________________                                    

The generic case statement selects an API and executes a block of codethat defines and creates a specific control type. For example, thisblock of code will invoke the specific API to define and draw the givenchild window. Some examples of the actual code required in ProgramManager to define the respective controls are: I List Box (control ID,parent ID), I Radio Button (control ID, parent, owner, coordinates); IPush Button (control ID, parent, owner, coordinates), etc.

Next, for each control type, a handle or pointer is retrieved from theAPI relating to the specific control type (e.g., Check Box, Entry Field,List Box, Push Button or Radio Box). The handle or pointer may appear as"Handle to Check Box=Create Check Box". The return from this API is theactual pointer value of the respective window. The code will ultimatelygenerate a linked list of all like pointers, as discussed in furtherdetail below.

For example, for the Check Box a handle is retrieved from the API to theCheck Box. The handle is the unique ID returned by the API to create anywindow. The handle allows the program to send commands to a particularwindow. Every opened window has a unique handle, defined by thegraphical manager (e.g., PM for OS/2 defines a handle for everysuccessfully defined window on the display screen).

Next, an identification code and the handle is associated with eachcontrol type. This association is made when the API called uponsuccessfully executes and defines the window. The return of a handlevalue means the code communicated properly to the Program Manager theelements for drawing a window or a control.

For example, an integer value (ID) and pointer or handle is stored tothe control type (e.g., Check Box, Entry Field, etc.). The integer valuerepresents the identification code.

Next, a previous node is linked to the next node and a linked list ofall like pointers is created. A single node will store values for agiven control. For example, a node for a push button will contain:

1) A unique ID for a push button;

2) A Handle to the push button;

3) A pointer to the next Node; and

4) A pointer to the previous Node.

FIG. 6 illustrates a Linked List for push buttons. The Linked Liststarts with push button 61 which has a pointer to the next node (pushbutton 62). However, the pointer to the previous node has a null value.Therefore, in effect push button 61 only has a pointer to push button62. Push button 62 has a pointer to the previous node, push button 61,and a pointer to the next node, push button 63. Push button 63 only hasan effective pointer to the previous node, push button 62. The pointerto the next node in push button 63 has a null value. Therefore, pushbutton 63 is the end of the Linked List.

The linked list of nodes may contain, for example, a plurality of fieldsto include a pointer to link to the next node within the given list, aninteger value of unique ID of the newly defined control field, and ahandle to the control window. The Linked List is a data structure tostore Information for newly created control windows.

This allows the calling program to traverse the chains of predefinedcontrol types established in the linked list to retrieve individualhandles of the requested child windows. The calling program will becoded to display the main window. The calling program will call thepseudo code, shown above, and the pseudo code will draw and define allrequired controls and return the same to the calling program. Similarly,other programs will call the pseudo code and the pseudo code will drawand define the required controls and return the same to the othercalling programs.

The inventive method can be implemented on any higher level language.For example, it can be implemented on a PS2 with the OS2 operatingsystem using an IBM CSET/2 compiler. However, while the method isoptimized for the OS2, it is advantageously used with any window-basedsystem such as AIX and NT.

The inventive method allows user interfaces to be altered at any timethroughout the life of the AP without requiring changes to the hard codeof the AP. By not altering the hard code of AP, the compilation time ofchanges is reduced since only rules defined in the database (be itrelational or flat files) need be changed. Therefore, the programmer canrun the executable file to read the rule tables and see the results ofnew rules on-line (e.g. in real-time on the screen), and the chance ofintroducing "bugs" into the program is substantially reduced. Once themain code is developed, compiled and linked into a executable file, itdoes not need to be changed. Adding a new window is as simple as addinga new rule (one row) into the rule table.

Further, according to this method, the same code can be used to arrangethe layout of controls in other parent window, thereby savingsubstantially on software development and maintenance costs. Therefore,the method is useful for a variety of applications, such as an on-linetool implementation.

Main windows for an application can also be designed by using the samemethodology given above. The rule table will be different and so willthe code as will be well understood by the ordinarily skilled artisan.

While the invention has been described in terms of a single preferredembodiment, those skilled in the art will recognize that the inventioncan be practiced with modification within the spirit and scope of theappended claims.

Having thus described our invention, what we claim as new and desire tosecure by letters patent is as follows:
 1. A computer-implemented methodfor a system having a plurality of application software interfaces, saidmethod comprising steps of:preparing a customized database includingcoordinates and control types of customized window setups for saidapplication software interfaces, said customized database comprising atable including one of a control type column, a coordinates column, anidentification code column, a parent window column, an owner windowcolumn and a miscellaneous information column; reading a control typefrom said control types stored in said database; selecting anapplication software interface having a pointer based on said controltype; defining an identification code for said control type; storingsaid pointer and said identification code in said database; forming acustomized window layout based on said database; and linking a firstnode to a second, subsequent node of control types and creating a linkedlist of said plurality of control types.
 2. A method as in claim 1,further comprising a step of defining an application software interface(ASI) for each respective one of said at least one control type andretrieving a pointer from each ASI to its respective control type.
 3. Amethod as in claim 1, wherein said customized window layout is alterablewithout altering an application software code.
 4. A method as in claim1, wherein said database executes said application code and saidapplication program is devoid of any hard coding of controls.
 5. Amethod as in claim 1, wherein said preparing step customizes said windowlayouts for each of said application software interfaces.
 6. Acomputer-implemented method for developing customized application windowsetups, said method for a system having a plurality of applicationprogram interfaces, said method comprising steps of:preparing acustomized database including coordinates and control types of saidcustomized application window setups, said customized databasecomprising a table including one of a control type column, a coordinatescolumn, an identification code column, a parent window column, an ownerwindow column and a miscellaneous information column; reading in atleast one control type from said control types stored in said database;defining an application program interface (API) for each respective oneof said at least one control type and retrieving a pointer from each APIto its respective control type; storing a value and pointer for saidcontrol type in said database forming a customized window layout basedon said database; and linking a first node to a second, subsequent nodeof said plurality of control types and creating a linked list of saidplurality of control types, wherein a same application code is reusablefor at least two customized window layouts of said application windowsetup.
 7. A method as in claim 6, wherein said customized window layoutis alterable without altering an application software code.
 8. A methodas in claim 6, wherein said database executes said application code andsaid application program is devoid of any hard coding of controls.
 9. Amethod as in claim 6, wherein said preparing step customizes said windowlayouts for each of said application software interfaces.
 10. Acomputer-implemented method for developing customized application windowsetups, said method for a system having a plurality of applicationsoftware interfaces for an application program, said method comprisingsteps of:preparing a customized table including coordinates and controltypes of said application customized window setups for said applicationsoftware interfaces, said table further including one of a control typecolumn, a coordinates column, an identification code column, a parentwindow column, an owner window column and a miscellaneous informationcolumn; reading a control type from said control types stored in saiddatabase; selecting an application software interface having a pointerbased on said control type; defining an identification code for saidcontrol type; storing said pointer and said identification code in saiddatabase, wherein said database is separate from said applicationprogram; forming a customized window layout based on said database; andlinking a first node to a second, subsequent node of control types andcreating a linked list of said plurality of control types, wherein saidcustomized window layout is alterable without altering an applicationsoftware code, and wherein said database executes said application codeand said application program is devoid of any hard coding of controls.11. A method as in claim 10, wherein said preparing step customizes saidwindow layouts for each of said application software interfaces.
 12. Anapparatus for developing customized application window setups based onpredefined rules, said apparatus comprising:a database for storing saidpredefined rules, said predefined rules including coordinates andcontrol types of said customized application window setups, saiddatabase comprising a table including one of a control type column, acoordinates column, an identification code column, a parent windowcolumn, an owner window column and a miscellaneous information column; aplurality of application software interfaces for an application program;means for reading a control type from said control types stored in saiddatabase; means for selecting an application software interface having apointer based on said control type; means for defining an identificationcode for said control type; means for storing said pointer and saididentification code in said database, wherein said database is separatefrom said application program; means for forming a customized windowlayout based on said database; and means for linking a first node to asecond, subsequent node of control types and creating a linked list ofsaid plurality of control types.
 13. A method as in claim 12, whereinsaid customized window layout is alterable without altering anapplication software code.
 14. An apparatus as in claim 12, wherein saiddatabase executes said application code and said application program isdevoid of any hard coding of controls.
 15. An apparatus as in claim 12,wherein preparing means customizes said window layouts for each of saidapplication software interfaces.